前言

會有這個系列文，一方面是幹資料工程師也有一陣子了，一直想有機會能把工作所用所學的東西做知識管理；另一方面也是希望督促自己不要怠惰，工作之餘還是能抓時間讀文件，繼續增進所學。

正巧公司辦著《資料密集型應用系統設計》(江湖人稱 DDIA) 讀書會，也聽聞同事參加了去年的 IThome 鐵人賽頗有心得，想著何不拿讀書會整理的筆記結合近期搞資料湖倉的心得來寫寫文章練練手，管理工作知識之餘還能拿文章來參賽，也可謂是一舉兩得了。

本次系列文大標《動不動就要 ETL? 從資料倉儲到湖倉》- Trino on Iceberg 30 日實戰筆記

主要是想以工作專案使用之Trino為例，分享近年新興數據架構 — 資料湖倉(Data Lakehouse) 之概念，以及自資料倉儲(Data Warehouse)轉換至資料湖倉(Data Lakehouse)之實作、所遇問題和解決方法，還有一些個人淺見，期望能拋磚引玉，撰文之際還可得領域翹楚們相互指教。

什麼是交易

對於在金融業待過4年的我，交易可說是再自然不過的詞，不過在資料工程內，交易代表的意思可不僅限於轉帳存提等金融交易了，要搞懂交易得先了解應用程式 與 資料庫 之間的關係。

應用程式 (可以是網頁或是 app) 負責面對客戶端的請求 (如 : 查詢你在帳戶的餘額)，將請求送至 Web server，再將請求轉至 Aplication server 去和資料庫要資料，最後再將所要資料沿原路返回給客戶端。

像上述這樣一個完整的請求到拿回資料的過程稱作一個交易 (transaction)，根據 DDIA 裡面交易的定義：

交易 (transaction) 是應用程式將多個讀寫操作組合成一個邏輯單元的方式．

可見交易通常不是只有單一的讀寫請求，例如：小明今天轉了一百元給小華，則這筆交易將會同時修改小明和小華的帳戶餘額。

而在交易中，最重要也最常被各式有交易保證的資料庫產品提到的概念，就是交易安全保證 — ACID：

ACID 是四個交易所提供的安全保證的英文頭一個字母的縮寫，包含了：

• 原子性 (atomicity): 資料庫狀態僅有交易操作前、交易完成後兩個狀態．意指不會有交易操作到一半這樣的狀態，即操作中間出錯的話資料庫可以終止並回滾至還沒進行操作時的狀態。
• 一致性(consistency): 應用程式資料庫應處於「良好狀態」。意指資料庫不會違背應用程式設下的約束，例如帳戶的借貸兩方必須平衡。
• 隔離性(isolation): 併發執行的交易間是彼此隔離的。意指所有併發執行的交易是可假裝自己是資料庫上唯一運行的交易。
• 持久性(durability): 一旦交易提交成功，寫入資料庫的資料就不會消失。意指資料庫已寫入硬碟或即便系統重啟也可以復原的地方。

為避免偏離系列主題，故本文不就 ACID 的實作方式做深入討論，有興趣的讀者可以參考 DDIA 第七章 — 交易，裡面有四種安全保證在各式資料庫裡頭實作的詳細介紹，非常建議閱讀。

簡單了解交易之後，會知道其實對系統來說，要保證交易不要出錯實在是太難了，要提供如上述的 ACID 安全保證，同時還會遇到包含：

• 資料庫軟體故障
• 應用程式故障
• 網路中斷
• 客戶端同時寫入 (併發交易)

等不及備載的問題，光處理這些便一個頭兩個大，哪還有心力把資源分給資料分析甚至是 AI 建模等工作的餘裕呢？

明日預告

系列文明日《交易型倉儲？分析型倉儲？》將接續今日文末問題，解析了為何用來處理日常業務交易的 OLTP資料庫不適合拿來做分析。

並解釋資料倉儲的概念，以及說明 ETL 這種自 OLTP 資料庫同步資料過來做分析的過程，如何解決了資料分析人員的危機。

Know me more

My Linkedin: https://www.linkedin.com/in/benny0624/
My Medium: https://hndsmhsu.medium.com/